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At present each neutron scattering facility has its own set of data 
treatment software, normally based on a proprietary data format. The 
travelling scientist is either forced to continually learn new software or to 
write conversion routines for his own software tools. 

During software development most of the time is spent on routines 
connected with file input and output or visualisation. Our aim is to relieve 
the scientist from such tedious work to allow maximum effort to be spent 
on data processing routines. 

I present an "Open Source" component based, extendable, platform 
independent framework for visualisation and transformation of data. 

Most of the existing software appears as a monolithic block. In con- 
trast openDaVE is built up in a modular design. It consists of three 
parts: the kernel, a lot of modules, and some different front-ends. The 
actual functionality of the framework is done by the modules. The kernel 
provides the creation, the destruction of the modules, and the interaction 
between them, whereas the front-end interacts with the user. 

The modules are divided into three classes: sources, filters, and sinks. 
Each of the module consists of two different parts: the module logic and 
one or more interfaces which set the module parameters. The interfaces 
are front-end specific. 
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1 Introduction 



A lot of scientists in the neutron scattering community is travelling from one neutron 
source to another. Most of them spent only some days at a certain instrument. 

During their work at different experiments at the various neutron sources they have 
to learn continually the use of the specific software packages for the pre-analysis of the 
data. To overcome this constant learning process they may use their own software, 
but they have to write new modules for accessing the data in the experiment specific 
data format. 

For analysis and interpretation they get the experimental data in electronic form 
(on disc, by email, direct access, etc) mostly in an instrument specific data format, 
whereas the own software at home uses a significantly different data format. 

That means for a large amount of time a scientist is occupied by learning the 
handling of new software or by writing routines for data conversions. This problems 
lead to a project in the FRM-II software group to give all users a tool solving this 
problems: 

openDaVE (open Data Visualization Environment). 

2 Features 

The main goal during the development was to achieve flexibility in many fields, which 
is provided by the following design rules: 

• component based architecture 

• simple extensibility 

• replaceable front-ends 

• replaceable data types 

The openDaVE framework was written in C++ using the Qt library |]J under 
Linux. This decision allows a simple porting to other operating systems such as 
Windows and the different flavors of UNIX. The current version runs under Linux 
and Windows. 

openDaVE supports a lot of data formats, but one of the most interesting data 
formats is NeXus M. The NeXus support includes: 

• reading and writing of NeXus file 

• browsing of the NeXus structure in a file 

• conversion into NeXus format 
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• export into non-NeXus formats 



• selection of data from a complex NeXus file containing more than one NXdata 
entry 

In contrast to most of the existing software, openDaVE was not designed as a 
monolithic program. It was built in a modular fashion, consisting of three parts: 

• the front-ends 

• the modules 

• the kernel 

This modularity is one most powerful features of openDaVE. It neither restricts 
the data used inside and outside openDaVE nor restricts anybody in the selection 
of functionality and user interface. 

The different set-up's of openDaVE are saved in XML files. 

3 System Design 

The collaboration of the three parts of openDaVE is shown in figure |l|. 
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Figure 1: Schematic layout of the components of openDaVE. 



2 



3.1 Front-ends 



The main aspect of the front-end in view of architecture is its exchangeability. It has 
access to the application via the module and kernel interface. These two interfaces 
are designed to implement a wide variety of front-ends. 
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Figure 2: Screenshot from a running qdave 

At this time we have implemented these types of front-ends: 

• Qt based front-end (see figure 0) qdave 

• Text based front-end tdave 

• Python bases front-end (under development) 

3.2 The Modules 

The actual functionality of the framework is incorporated into the modules. That 
means an extension of the functionality of the whole framework is done by developing 
a new module. 

A module is realised as a shared library being loaded dynamically by the kernel 
at runtime, on request of the user. This library provides a well defined interface to 
the kernel (the kernel accesses the module logic through this interface), the module 
logic (functionality), and one or more interfaces to the user which may be used by 
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the front-ends to control the behaviour of the module logic. So the user may set and 
get the module parameters. 

The creation and deletion of a module instance is done by the kernel. If a module 
instance is created by the kernel, exactly one user interface is provided although the 
library may provide more than one. 

3.2.1 Module functionality 

There exist three types of modules: 

• Sources 

• Filters 

• Sinks 

The differences between these types are the following: 

• a source has only output data in the meaning of the openDaVE architecture 
(for example reading the NeXus data file) 

• a sink has only input data (e.g. writing the data into a NeXus file, display the 
data) 

• whereas a filter has input as well as output data (for example smoothing a 
spectrum) . 

Each module has a certain input and output type which may differ inside one module. 

The data in openDaVE may only flow from a source trough one or more filters 
to a sink. One may consider the data flow as a chain of modules which has to start 
with a source (or filter) and has to end with a sink (or filter) (see figure §). The 
kernel ensures that only modules with the same output and input parameter may be 
connected. 

The functionality of a module is encapsulated in a single function call. This 
function is always called when the kernel decides that a module has to recalculate 
its data. It receives the data from all in-links as parameters. The calculated data 
of the module must be returned at the end of the function call. So the data can be 
delegated by the kernel to all out-links of the module. The number of in-links can be 
restricted by the developer of the module. 

The data flow may be initialized by a source (a source module creates new output 
data, which should be processed by the following module chain) via filters to the sink 
in the so-called real-time mode, or from a sink (the user wants to reprocess the data 
with changed module parameters) via filters to the source. In any case the data flow 
from source to sink. 
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Figure 3: Some examples for the data flow in openDaVE 



The mode may be set separately for each module, and the modules may be used 
also in a mixed mode. However, a source initiated data flow breaks at a module which 
is not set to the real-time mode. 



3.3 The Kernel 

The kernel may be considered as the heart of openDaVE. Its main task is to manage 
the modules, meaning that it has to create and delete some instances of the modules. 
Additionally it has to establish and remove the dataflow between the modules. Let's 
have a deeper look into the kernel. 

Through the front-end instructs the user the kernel to create or to delete a module 
instance. Let's consider the creation process. The kernel needs an information about 
the type of module to be created, the interface the module has to provide, and the 
name of the module instance. In its table of modules the kernel looks for the type of 
module which it may create (This table is filled up when the kernel loads the different 
module libraries). If the type was found the kernel creates a module instance. The 
module itself tests the existence of the desired interface. If all searching was succesful 
the module instance is created and may be used trough the interface by the user. 

After creating of the module instances they have to connect among themselves. 
This connection will be established by the kernel on request of the user. It checks 
whether the connection (link) is going from a source/filter to a filter /sink (see figure 
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H). Futhermore it checks, whether the output and input data types are the same, and 
that the maximum number of input links to the ending module is not reached. 

The deletion of a module requires some works of the kernel. At first it has to 
check the input and output links to this module. If there exist any, it has to stop 
the dataflow between the modules through them. Afterwards it removes these links 
before it removes the module itself. 

4 Summary 

This paper gives an overview on openDaVE, a modular, open, extensible framework 
for data analysis and data interpretation. It is shown how the several parts of the 
framework collaborate. 
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